With the advancement of the computer industry, the use of payment devices such as cards, typically magnetic stripe cards or smartcards, has become the preferred method of transacting business. Using such payment cards simplifies the purchase of goods and/or services by avoiding the necessity of using cash for such transactions. Facilitating the use of these payment cards are electronic payment or card accepting terminals, such as credit card reading terminals.
In recent years, an electronic wallet system has been suggested in which a monetary amount can be exchanged by communication between integrated circuit (“IC”) cards or between an IC card and a point of sale (“POS”) terminal. The IC card used for this system includes a microprocessor having a communication function and a memory such as electrically erasable programmable read-only memory (“EEPROM”) for storing a processing program, such as the MONDEX™ electronic cash application developed by Mondex International, Ltd. The processing program is capable of configuring the IC card to function as a credit card, a debit card or an electronic cash card.
If configured to function as a cash card, the IC card can be used for offline commercial transactions of merchandises, commodities and the like, and to allow information or data representing a monetary amount to be stored in a memory incorporated in the IC card. When the IC card runs out of electronic cash, the cardholder must deposit additional cash onto the IC card using a specialized terminal.
In a typical transaction involving the purchase of an item or of a service, the payment device is presented at a point of sale terminal (“POS terminal”). The POS terminal has a card reader that can read data stored on the payment device, this data including identification or authentication data. Independent of whether the payment device is configured as a cash, credit or debit card, information of the monetary amount involved in the transaction is transferred to the POS terminal, which initiates an authorization request for an eventual authorization from a payment card issuing agency. Accordingly, data read from the payment device is provided to the merchant's transaction processing system and then to an Acquirer, which is typically a bank or other institution that manages the merchant's account. The data provided to the Acquirer may then be provided to a payment network where the transaction data is processed to determine if the transaction should be authorized. Clearance and account settlement for completed transactions are also performed on the payment network. Whether the IC card is configured as a credit card or a debit card, the cardholder must have a credit account or a bank account, respectively, known by the issuing agency in order to use the IC card. Communication between the payment network and the bank (known as the Issuer) that issued the payment device to the consumer may be required to complete the transaction. The Issuer can send data back to the payment device an Issuer Update of records of the transactions, e.g. a current balance. This can be achieved by setting or resetting a counter. Authorization for the transaction does not always need to be obtained from the Issuer. The payment device may be provided with a pre-authorized limit representing the maximum value which may be utilized with said device for at least one off-line transaction without communication with said payment network for authorization of said transaction.
The EMV transaction flow begins when the payment device is read at a terminal, e.g. is inserted into a reader at the merchant terminal. The terminal reads data from the card for use in its risk management and to establish the card authenticity. There are two types of card authentication, Static and Dynamic Data Authentication (SDA and DDA), where not all cards support DDA. DDA is further divided into basic DDA and DDA combined with Application Cryptogram generation (called CDA, which stands for Combined DDA/AC Generation). For the card to support DDA it must have its own signature key pair and the means to generate signatures. In both cases the terminal uses a stored copy of the card brand public key to verify the issuer public key certificate; in DDA, the terminal also verifies an issuer-signed certificate for the card public key. In SDA, the terminal verifies the issuer's signature on critical card resident data so that unauthorized alteration of issuer data after personalization is detected. In DDA, the terminal uses a public key based challenge response protocol to authenticate the card and verify the integrity of card resident data.
Next the Cardholder verification method is invoked to ensure that the person presenting the card is the one to whom the card was issued. For this purpose EMV uses a secret PIN, where this PIN can be verified either offline by the card or online by the issuer. Upon successful cardholder verification, the terminal then performs terminal risk management and decides whether the transaction should be approved offline, declined offline, or an online authorization is necessary. Providing it does not reject the payment at this stage, the terminal passes the payment request to the card in the form of a GENERATE AC command. In response, the card performs its own card risk management and card ‘action analysis’. Depending on the card risk management policy the card's action analysis can return one of three results:                1. A Transaction Certificate (TC), when the payment is approved offline.        2. An Authorisation ReQuest Cryptogram (ARQC), when either the card or the terminal want to go online so that the issuer can authorize or reject the transaction. The issuer then responds with an Authorisation ResPonse Cryptogram (ARPC) which the card verifies and acts on. The terminal then issues a second GENERATE AC command that includes the issuer response. If the transaction is approved by the issuer, the card computes a transaction certificate (TC).        3. An Application Authentication Cryptogram (AAC), when the request is declined.        
Finally, by returning either a TC or an AAC to either the first or second GENERATE AC command issued by the terminal, the card indicates its willingness to complete transaction processing. If the terminal or card decides to go online, completion shall be achieved when the second GENERATE AC command is issued.
Payment products, such as pre-authorized or offline-prepaid products, rely on a balance managed by the card and updated by the Issuer. For purpose of these updates, the Issuer needs to be able to send balance update instructions in a trustable and reliable manner to the payment device. The terminal and network infrastructure based on the EMV specifications and provided by EMVCo allows updates as part of an online authorization response and implements three mechanisms for doing so:                Updates prior to the second Generate AC—the so-called critical scripts (tag 71, see EMV specifications)        Issuer Authentication data, sent as part of the second Generate AC (tag 91, see EMV specifications) or in an External Authenticate command (see EMV Specifications)        Updates after the second Generate AC—the so-called non-critical scripts (tag 72, see EMV specifications).        
Existing network infrastructure imposes limitations on the size of the updates the issuer can send: for example issuer scripts can be limited to 124 bytes and issuer authentication data can be limited to 16 bytes. This causes an inconvenience to the issuer. In addition, these three methods, using tags 71, 91 and 72 are not linked together giving rise to the possibility of errors. Also if the updates are written to non-volatile memory a problem can occur if the process is aborted prematurely. In that case, the values already written to non-volatile memory must be rolled back to the old values. This can involve storing both sets of values in non-volatile memory and then updating address data to point to one or other of the sets of data depending on the successful or unsuccessful completion of the transaction. It would be preferred if the Issuer Updates could be carried out in a more convenient manner.